Interesting post Mike.  But I'm going to have to disagree with you.  

I think the @formula addition to XPages is important to Notes Developers getting started in XPages but should be abandoned as soon as possible.  While for the most part they do work and provide a service to the developers toolbox, I think in the bigger picture they are a crutch and will hinder the developer from learning more and creating better apps in the long run.

I pretty much use a single @formula in my development.   @Unique.  Because I like how that generates unique keys.  Ok I probably use @Name() on occasion as well but I really can't think of another @formula that i regularly user or want to use. Funny that I can't even use @Unique() straight in XPages. That returns some kind of Java random number - its very long.  So I wrap  that in an Eval to get to the older classic Notes Client key version.

Look at @DbLookup.  How useful is it really?  If a single value it returns a string.  Multiple values it returns an array.  There's a 64k Limit.  I think it would be much better to user the domino object model inside SSJS or Java to do the desired function.   @Formula has lots of string handling capabilities.  But again - you can do all the same in JavaScript and Java and now you're also learning something that's more standard and can translate to other environments. 

I'm not predicting it will go away and I think it's important that it exists - at least it was important for the first several years of XPages.  I think it's less important now that there's more information out.  But I highly recommend that @formula's in XPages be limited because there are better ways to do things.

I agree with Dave. When I started doing XPages stuff (after 15+ years of Native Notes Development) I used a fair number of @Formulas. As I have become more experienced (not an expert) I have abandoned most all of the @Functions and have gone back through most of my code and removed most all of the references to @Formulas. I continue to use the @Unique for the same reason that Dave has stated (an unchanging unique document identifier). I started using @DBLookup and @DBColumn a fair bit but abandoned that very early because I found that I could do the same thing in SSJS with far more control. Also as Dave has said I do use the @Name because I have not found an easy way to duplicate this function in JavaScript. It can be done but I have not found an easy way, but I'm guessing it is just because I have not found it yet.

This edit control is not working well for a tablet.

I'm not talking about Javascripting formula workalikes. I'm talking about profiling @functions to make the app more flexible.

The moment ystart talking about using Javascript to run some hardcoded @function workalike in the middle of a page youre not talking about what I'm seeing.

@Functions have allowed me to hand over an app and let an admin configure it. Extensively. It doesnt require me to upgrade all apps in a suite. Each app is flexible. Admins can open a profile, change a formula, a view name, and the app reads data differently off the new view.

So yeah, I want that much more than a hardcoded view & key.